1. Field of the Invention
This invention relates to common information model (CIM) indications, and particularly to methods, systems and computer program products for dynamic categorized event cool off for CIM indications.
2. Description of Background
Storage Management Initiative—Specification (SMIS) Agents for switches and fabrics are agents that are proxy to the switches or embedded on the switches and provide management information and control of the switches through the standard SMIS interface. A storage area network (SAN) Management client can subscribe to receive events from the SMIS Agent, known as common information model (CIM) Indications. Standard CIM Indications are defined and supported by the SMIS Agents for events such as: Active ZoneSet Changed; Full Zone Database Changed; Switch Port Operational Status Changed; Switch Operational Status Changed; Node Port or Node Discovered; and Node Port or Node Missing. SMIS Client applications can subscribe to each type of Indication by using defined “Filters”.
SMIS-enabled SAN management applications (“SMIS Clients”) may have “Handlers” for running post-indication algorithms for different categories of CIM Indications. These Handlers may make post-indication inquiries to the SMIS Agent in order to obtain further information. The set of post-indication requests made to the SMIS Agent may be dependent on the type of CIM Indication delivered.
SMIS Agents may enter into a state where a constant stream of indications is sent. This is commonly referred to as an Indications Storm. An example of this is Brocade CIM_InstModification Indications for switch ports flip-flopping from OperationalStatus of ‘okay’ to OperationalStatus of ‘unknown’. An Indications Storm can potentially cause several problems, including: 1) The SMIS Client can become busy trying to route all of the Indications to the appropriate processing methods for handling the indications, 2) The SMIS Client may be designed to have a limited number of CIM Client threads that can be running at once, which is a potential bottleneck for post-Indication Inquiries during an Indications Storm, and 3) Performance of the SMIS Agent may slow down because it is so busy generating Indications and processing a constant stream of post-Indication requests to the SMIS Agent.
The SMIS 1.1 specification includes a standard mechanism to suppress redundant indications. The SMIS Client defines the indication suppression policy at the time that the indications are subscribed to. The SMIS 1.1 specification defines a use of the RepeatNotificationPolicy property, which defines the desired behavior for handling Indications that report the occurrence of the same underlying event (e.g., the disk is still generating I/O errors and has not yet been repaired).
However, there are drawbacks and known issues to the solution defined in the SMIS 1.1 specification. One problem is that two or more Indication Filters may be routed to the same Handler. Another problem of the solution is that users of SMIS Client applications may prefer CIM Indication delivery suppression intervals to be a shorter time interval than a time interval used by the SMIS Client application for handling the CIM Indications. In addition, these SMIS Standard properties for suppressing Indications are not yet supported by some SMIS Agents. Furthermore, the user may desire that indication suppression intervals adjust dynamically during indication storm periods.
Another solution to handling an Indications storm is the implementation of Static and Common EventCoolOff, in which a SAN Management client uses an EventCoolOffPeriod that is static and commonly used for all indications. The EventCoolOffPeriod in this case would only process the last CIM Indication received for a fabric during the EventCoolOff period. However, there are also drawbacks for using a Static and Common EventCoolOff. Since SMIS has well-defined standard Indication Filters, a “single Handler for all fabric events” (i.e. “common”) approach should not be used. Multiple handlers is appropriate for SMIS, because each handler can trigger a different set of post-Indication requests to the SMIS Agents, based on the standard Indication Filter for which the CIM Indication was generated for. A common EventCoolOff period in this scenario would erroneously not process some CIM Indications because it would assume that handling of the last indication received during the EventCoolOffPeriod would discover all changes to the fabric that occurred during the EventCoolOffPeriod. SAN Management applications using a common EventCoolOffPeriod must also have a common post-event discovery algorithm for properly discovering all fabric changes. However such an implementation has inherent scalability and performance concerns because of the scope of the large discovery algorithm needed. In addition, the user may desire dynamically adjusting delay periods before handling the events rather than keep the delay period “static”. “Static” delay periods may be too small during periods of high activity on the fabric.